В этом видео мы погружаемся в мир развертывания кода в рабочей среде.
Ничто не сравнится с удовлетворением от того, что наш код доступен миллионам пользователей.
Это всегда волнующе видеть.
Но попасть туда не всегда просто.
Давайте рассмотрим некоторые из распространенных стратегий.
Одним из самых первых методов развертывания изменений в рабочей среде является развертывание Big Bang.
Представьте себе, что вы срываете лейкопластырь.
Мы отправляем все наши изменения сразу.
Это вызывает некоторое время простоя, так как мы должны выключить старую систему, чтобы включить
новый.
Время простоя обычно короткое, но будьте осторожны — если что-то пойдет не так, как планировалось, оно может ужалить.
Подготовка и тестирование являются ключевыми.
Если что-то пойдет не так?
Откатываемся на предыдущую версию.
Откат назад не всегда безболезненный.
Мы по-прежнему можем нарушать работу пользователей, и это может иметь последствия для данных.
Нам нужен четкий план отката.
Большой взрыв иногда является единственным выходом, например, при сложном обновлении базы данных.
вовлечен.
Затем у нас есть скользящее развертывание.
Это больше похоже на марафон, чем на спринт.
Этот метод позволяет постепенно обновлять различные части системы.
Это поэтапное развертывание, при котором мы постепенно развертываем новую версию приложения на
производственная среда.
Вот пример того, как это может работать.
Представьте, что у нас есть 10 серверов, на которых запущено наше приложение.
В непрерывном развертывании мы можем отключить первый сервер, развернуть новую версию
наше приложение там, и вернуть его в Интернете.
Как только мы подтвердим, что все работает как положено, мы перейдем ко второму серверу.
и так далее.
Такой подход позволяет новой версии постепенно заменять старую, сервер за сервером, пока
вся система обновлена.
Одним из больших преимуществ последовательного развертывания является то, что оно обычно предотвращает простои.
Пока мы обновляем один сервер, остальные все еще работают и обслуживают наших пользователей.
Еще одно преимущество заключается в том, что мы можем обнаружить и устранить любые проблемы на раннем этапе развертывания.
Это снижает риск широко распространенных проблем.
Мы постоянно открываем новую версию только для небольшой части нашей системы.
Однако последовательное развертывание обычно является более медленным процессом.
И хотя это снижает риск общесистемных проблем, оно не устраняет его полностью.
Если проблема ускользает от наших первоначальных проверок, она может все еще распространяться, когда мы обновляем больше
серверы.
Эта стратегия не поддерживает целевое развертывание.
Мы не можем контролировать, какие пользователи получат новую версию во время развертывания.
Все пользователи постепенно увидят новую версию по мере обновления серверов.
Мы не можем направить новую версию конкретным пользователям на основе таких критериев, как местоположение, устройство
тип и т.д.
Скользящее развертывание — популярный выбор для многих команд.
Он уравновешивает риск и воздействие на пользователя контролируемым и методичным образом.
Теперь давайте взглянем на сине-зеленое развертывание.
Здесь мы поддерживаем две идентичные производственные среды, умно названные синей и зеленой.
В любой момент времени одна сторона активна и видна пользователям, а другая простаивает.
Активная среда (скажем, синяя) обслуживает текущую живую версию приложения.
пользователям.
Простой (зеленый) — это наша игровая площадка, где мы можем безопасно развернуть и протестировать новую версию.
Вот как это может работать.
Когда у нас есть новая версия, готовая к работе, мы развертываем ее в зеленой среде.
Пока это происходит, синяя среда все еще работает и обслуживает текущую версию.
приложения для пользователей.
Затем наша группа контроля качества тестирует новую версию в зеленой среде.
Это дает нам возможность выявлять и исправлять любые ошибки или проблемы до того, как они попадут к нашим пользователям.
Как только новая версия в зеленой среде считается готовой, мы просто переключаем нагрузку
балансировщик для перенаправления трафика из синей среды в зеленую.
Пользователи плавно переходят на новую версию приложения с нулевым временем простоя.
Теперь синяя среда становится бездействующей и служит нашей подстраховкой.
Если мы столкнемся с какими-либо проблемами с новой версией,
мы можем быстро переключиться обратно в синюю среду,
эффективный откат к предыдущей версии.
В то время как сине-зеленое развертывание обеспечивает плавный переход и простой откат, существует
ловить.
Как и в случае последовательного развертывания, мы не можем направить новую версию конкретным пользователям.
Переключение с синего на зеленый происходит для всех пользователей одновременно.
Это также ресурсоемко.
Поддержка двух идентичных производственных сред удваивает потребность в инфраструктуре и ресурсах.
Мы могли бы сократить время простоя среды между развертываниями, но это усложняет работу.
Управление двумя параллельными производственными средами и обеспечение бесшовной синхронизации данных
может значительно усложнить процесс развертывания.
Требуется сложное управление инфраструктурой
и оснастка.
Тем не менее, благодаря высокому уровню контроля и минимальному риску, Blue-Green Deployment остается
популярная стратегия для удобного взаимодействия с пользователем и надежных откатов.
Далее идет Canary Deployment, названный в честь вековой практики использования канареек в
угольных шахт для обнаружения опасных газов.
Если канарейка попала в беду, м
Инерс знал, что пришло время эвакуироваться.
Точно так же при развертывании программного обеспечения мы используем
эта стратегия для «проверки воздуха» перед полномасштабным
посадочная дистанция.
Вот как это происходит.
Вместо развертывания новой версии для всех серверов или пользователей мы выбираем небольшое подмножество,
наши "канареечки".
Это может быть процент серверов или группа пользователей, часто выбранная на основе определенных
критерии.
Например, мы можем начать с развертывания на одном сервере, или в небольшом кластере, или даже
определенного географического положения.
Это позволяет нам отслеживать производительность новой версии в реальных условиях,
но в гораздо меньших масштабах.
Если все пойдет хорошо и наша новая версия будет работать так, как ожидалось, мы можем постепенно
его остальным серверам или пользователям.
Но если что-то пойдет не так, у нас есть подстраховка.
Мы можем остановить развертывание, исправить проблемы и повторить попытку, и все это не повлияет на большинство
нашей пользовательской базы.
Этот поэтапный подход предлагает нам как безопасность, так и контроль.
Canary Deployment также дает нам возможность целенаправленного развертывания.
В отличие от непрерывного или сине-зеленого развертывания, мы можем направлять наших канареек на основе пользовательских
критерии, такие как географическое положение или тип устройства.
Однако у Canary Deployment есть свои проблемы.
Это требует тщательного мониторинга и автоматизированного тестирования канареек.
Это требует несколько сложных инфраструктурных инструментов для ускорения или остановки развертывания по мере необходимости.
Стратегия может быть сложной для реализации и управления, особенно при работе с базой данных.
изменения схемы или проблемы совместимости API.
Canary Deployment обычно не является отдельной стратегией.
Его часто сочетают с последовательным развертыванием, чтобы создать подход, объединяющий
лучшее из обоих миров.
Наконец, в качестве бонусной стратегии у нас есть Feature Toggle.
Она немного отличается от других стратегий, которые мы обсуждали.
Речь идет не о развертывании новой версии всего приложения, а об управлении
конкретные новые функции в этом приложении.
С Feature Toggle мы вводим в код «переключатель» или «переключатель» для новых функций.
Это позволяет нам включать или выключать функцию для определенных пользователей или обстоятельств.
Думайте об этом как о воротах, которые мы можем открыть или закрыть.
Он контролирует, кто увидит новую функцию.
Feature Toggle можно использовать в сочетании с любой из предложенных нами стратегий развертывания.
обсуждалось.
Допустим, мы делаем Canary Deployment.
Мы можем включить переключатель функций только для канареечных пользователей, позволяя им протестировать
новая функция, в то время как остальная часть пользовательской базы продолжает использовать текущую версию.
Feature Toggle предлагает отличный контроль над новыми функциями и позволяет целевому пользователю
тестирование.
Это отлично подходит для A/B-тестирования или постепенного развертывания функции, чтобы увидеть, как она работает.
Однако у Feature Toggle есть свои недостатки.
Если не управлять должным образом, переключатели могут добавить сложности
в кодовую базу и усложнить тестирование.
Старые или устаревшие переключатели необходимо очистить, чтобы предотвратить «задолженность по переключателям», которая может
систему становится все труднее поддерживать.
Итак, у вас есть это!
Пять стратегий развертывания, каждая со своими сильными сторонами, проблемами и вариантами использования.
Помните, лучшая стратегия зависит от
характеристики приложения и ожидания пользователей.
Теперь дело за вами: какие стратегии развертывания вы использовали?
Что сработало лучше всего для вашей команды?
Давайте обсудим в комментариях ниже.
Если вам нравятся наши видео, вам также может понравиться наш информационный бюллетень по проектированию систем.
Он охватывает темы и тенденции в проектировании крупномасштабных систем, которым доверяют 400 тысяч читателей.
Подпишитесь на blog.bytebytego.com